Date: Fri, 26 Aug 94 04:30:20 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #285 To: Ham-Digital Ham-Digital Digest Fri, 26 Aug 94 Volume 94 : Issue 285 Today's Topics: HF -> internet gateways? HF Packet (Mac vs PC) HP100LX + Baycomm = Success? jnos trace question (2 msgs) jnos w/enet card mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies Packet Routing with JNOS 110f What SB for Digital modes? Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 25 Aug 1994 23:37:22 GMT From: andyh@ucsd.edu Subject: HF -> internet gateways? To: ham-digital@ucsd.edu i'm looking for gateways which can receive pactor, amtor, gtor or rtty messages on HF and send them to an internet e-mail address. i'd be most grateful if anyone who knows of such things could email me details. i'll compile and post the results. thanks, andy howard ------------------------------ Date: 25 Aug 1994 03:01:52 GMT From: news.sprintlink.net!sun.cais.com!news.cais.com!news@uunet.uu.net Subject: HF Packet (Mac vs PC) To: ham-digital@ucsd.edu Go ahead and get a Mac for this project,the software needed for what you want to do exists and is sold by the major TNC manufacturers. I heartdly recomend a Kam all mode TNC and Hostmaster for Mac from Kantronics.If you cant get a source or number for the manufacturer,send me some e-mail,I'll get it to you ------------------------------ Date: Thu, 25 Aug 1994 05:40:07 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu Subject: HP100LX + Baycomm = Success? To: ham-digital@ucsd.edu J. Sherwood Williams (jwill@cabell.vcu.edu) wrote: : : Has anyone had any success using a Baycom type modem with the HP : 100LX palmtop? Before I go out and mess with it, it would be good The HP100LX works fine once the Baycom is powered by a 9 volt battery. Works even better with a PacComm HandiPacket and MSYS. With that it is a full forwarding BBS with all the goodies (node, etc.). In that way I can forward to the home BBS when I have mail to deliver and the home BBS can forward into me ... if I am there or not. We also ran it with a GTOR and Pactor port when running on a battery up in Algonquin Provintial Park. Worked great and saved all kinds of amp-hours as I didn't have to use the other laptop. I love it! 73, Steve ag807@cleveland.freenet.edu no8m@no8m.#neoh.oh.usa.na ------------------------------ Date: 25 Aug 1994 13:46:06 GMT From: noc.near.net!transfer.stratus.com!abersoch.sw.stratus.com!northup@uunet.uu.net Subject: jnos trace question To: ham-digital@ucsd.edu I have just started using jnos110f and have been having a problem with having a trace show up on the screen. I can make it go to a file. What am I missing ? Bill -- -- Bill Northup PHONE: (508) 460-2085 Stratus Computer Inc. INTERNET: northup@sw.stratus.com 55 Fairbanks Boulevard Packet: N1QPR@WA1PHY.#EMS.MA.USA.NA Marlboro, MA 01752 Amateur Radio: N1QPR ------------------------------ Date: 25 Aug 1994 08:16:23 -0700 From: nntp.crl.com!crl4.crl.com!not-for-mail@decwrl.dec.com Subject: jnos trace question To: ham-digital@ucsd.edu In article <33i7au$rr1@transfer.stratus.com>, northup@abersoch.sw.stratus.com (Bill Northup) wrote: > I have just started using jnos110f and have been having a problem > with having a trace show up on the screen. I can make it go to a > file. What am I missing ? An key. After you have entered "Trace xxxx" (where "xxxx" is the representation of the type of trace you wish), mash the key to see the results. You can tell if you mashed the key hard enough by observing the upper left corner of the CRT (3rd line down). It will change from "Command" to "Trace". Mashing again will toggle back to Command Mode. If you wish, you can use other F-keys to sequentially observe multiple active sessions; being session 1, being session 2, etc. Unfortunately, TRACE does not act like an independent session, and the TRACE screen will "freeze" if you are watching another session. Lou ------------------------Usual Disclaimers Apply------------------------- Internet: lgenco@crl.com Lou.Genco@LChance.sat.tx.us Ham Radio Packet: N5SGL @ K3WGF.#SAT.TX.USA tcp/ip: n5sgl@sat.ampr.org ------------------------------------------------------------------------ ------------------------------ Date: 25 Aug 1994 01:08:48 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!ix.netcom.com!netnews@network.ucsd.edu Subject: jnos w/enet card To: ham-digital@ucsd.edu I am running JNOS 1.10f and have installed gvc ethernet cards in my jnos pc and my other pc. The cards check out fine between the machines running the diagnostics. The supplied driver comforms to FTP specs. I have included the PACKET protocol in my config.h . THe attach works fine, but I cannot get jnos to recognize the packets I am sending to it. The trace on the port avails nothing. Any ideas or suggestions for debugging would greatly be appreciated, especially configuration options for jnos I may not have set correctly. Thanks. 73 de Bill Abernathy, kd5lu. ------------------------------ Date: Thu, 25 Aug 1994 02:42:38 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!ulowell!simtel.coast.net!msdos-ann-request@network.ucsd.edu Subject: mlhacker.zip - Zenith Minisport docs, hints, hacks & goodies To: ham-digital@ucsd.edu I have uploaded to the SimTel Software Repository (available by anonymous ftp from the primary mirror site OAK.Oakland.Edu and its mirrors): SimTel/msdos/packet/ mlhacker.zip Zenith Minisport docs, hints, hacks & goodies mlhacker.zip is a compendium of newsletters about the Zenith Minisport laptop computer and its use as a packet radio host computer. Zenith offers only minimal and expensive support for this popular but discontinued 8086 compatible notebook computer. Newsletters contain technical notes, construction projects, operating hints, resources, architecture details and other related goodies. The Minisport Laptop Hacker series is the result of owning and repairing Minisports and donations from others on Internet and the Amateur Radio packet networks. Special requirements: None Changes: Compendium includes Minisport Laptop Hacker #1 - #22. FreeText. Uploaded by the author. Brian Mork bmork@opus-ovh.spk.wa.us ka9snf@ka7fvv.#ewa.wa.usa 6006-B Eaker, Fairchild, WA 99O11 V:509-244-3764 D:509-244-9260 ------------------------------ Date: 25 Aug 1994 11:51:22 GMT From: news.cerf.net!gopher.sdsc.edu!news.tc.cornell.edu!travelers.mail.cornell.edu!news.kei.com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!gatech!howland.reston@ihnp4.ucsd.edu Subject: Packet Routing with JNOS 110f To: ham-digital@ucsd.edu I want to use JNOS as a packet switch between an AX25 serial link and an ether net segment. With the autoexec.nos listed below, I can ping machines on the 1.0.0/24 (ethernet) side of the net and I can ping machines on the 1.0.1/24 (AX.25) side of the net. The problem I have is that if I try to ping say 1.0.0.45 from 1.0.1.99, the packets dont go anywhere. The default route on my AX.25 machine is set to: route add default sl1 1.0.0.99 The way I figure it, 1.0.0.99 should see the ping for 1.0.0.45 from 1.0.1.99 and route ot from the AX.25 side out onto the ether net side but this isn't hapening. Is there something I'm not doing right? By the way, don't get upset about my IP numbers. None of these nets are connected to anything and just exist on an experimental test bed. ------------------------AUTOEXEC.NOS for 1.0.0.99------------ ## ip setup ip address 1.0.0.99 hostname dave.ards.dnd.ca. ## ax25 setup ax25 mycall dave ax25 bctext "ARDS testbed Daves Machine" ## attach interfaces attach asy 0x3f8 4 ax25 sl1 1025 768 9600 ifconfig sl1 ipaddress 1.0.1.99 ifconfig sl1 descr "AX25 Connection to Laptop" attach packet 60 lan1 100 1500 ifconfig lan1 ipaddress 1.0.0.99 ifconfig lan1 descr "Packet Connection to DLAEEM" ## Start Servers start ax25 start ftp start telnet ## Routing route add 1.0.1/24 sl1 route add 1.0.0/24 lan1 ip hport sl1 on ip hport lan1 on ax25 hport sl1 on -- |------------------------------------------------------------| | Captain Dave Mercer M.Eng., P.Eng. | | Directorate of Land Armament and | | Electronics Engineering and | | Maintenance 2-3-3 | | National Defence Headquarters | | Ottawa, Ontario, Canada | | K1A 0K2 | | | | Voice: (819) 997-9831 | | Fax: (819) 994-4246 | | EMail: mercer@dgs.dnd.ca | | HAM: VE3XMJ | |------------------------------------------------------------| -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3 mQCNAiw7jJkAAAEEALpAIvULlA/xvrzuR30NcLZE0HCHyGm5QR4ej8xM6k3AcH3T Q3NkgV2FK5f8t/fBAhO1+ffa5K7F10B4hPqKkAASNlk1PIx9ty5oUgxAlZnfya4V ScNIx0x2h2f3roRjiZLfNYM2zkm26sZhFQjVJxyNnluJq/xVb45/LyY+p9flAAUR tCBEYXZpZCBNZXJjZXIgPG1lcmNlckBuY3MuZG5kLmNhPg== =0azF -----END PGP PUBLIC KEY BLOCK----- ------------------------------ Date: Wed, 24 Aug 94 20:27:08 PDT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!svc.portal.com!portal!cup.portal.com!lgm@network.ucsd.edu Subject: What SB for Digital modes? To: ham-digital@ucsd.edu all digital is on LSB on 20 meters ------------------------------ Date: Thu, 25 Aug 1994 16:34:28 GMT From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!world!dts@network.ucsd.edu To: ham-digital@ucsd.edu References <1994Aug20.143652.9960@ke4zv.atl.ga.us>, , <33i45b$oao@acorn.acorn.co.uk>.com Subject : Re: Looking for DXCluster software In article <33i45b$oao@acorn.acorn.co.uk>, Adrian Godwin wrote: >In article , >Daniel T Senie wrote: >> >>How is the PacketCluster machine to know that the UI frame with a DX >>spot just got stomped by another station starting to transmit a frame? >>Packet radio does NOT run with Collision Detection in the way that >>Ethernet does. You cannot tell, when transmitting, that your frame >>has just gotten munched. >> > >It's not that difficult : most broadcast protocols work on a NAK-only >scheme - clients of the server respond only when they miss a packet, >and the server than retransmits it. >The method of detecting that missed packet varies, but a popular method >is to number the transmitted packets and complain when a hole appears in >the number sequence. Adrian, thanks for your comments, and this is exactly what I was trying to call out. There are certainly solutions such as numbered packets which can be implemented. Essentially what you're doing then is to create another protocol layered atop the broadcast mechanism. It's not that different from the multicast implementations. I was primarily pinting out that the "simple" solution that had been mentioned was not sufficient. > >This has some difficulties for a DX-Cluster style service : as I understand >it (I don't use DX Cluster) you expect transmissions at intervals, rather >than a continuous stream. Thus, you wouldn't know you missed one until >the next arrived - a second or an hour later. Regular empty packets, sent >just to ensure everyone was up to date, might be sufficent to fix this, >and there are more sophisticated schemes around to ensure this doesn't >itself become a bandwidth hog. These require that the server keep track >of its clients rather than doing pure broadcast, but that's no worse than >having multiple VCs. Exactly. The frequency of packets is an issue. It would be necessary to send out null packets every 30 seconds or so to ensure all stations received the broadcasts in a timely fashion. Even 30 seconds may be too long... At some point you really clog the channel with null packets placed there to ensure naks happen correctly when needed... > >However, I think you're correct to be concerned about low reliability of >packet systems - on typical terrestrial packet, the success rate is very >low. As a result, a protocol optimised for the assumption that most packets >get through (and don't require ACKing) might turn out disastrously wrong - >I think a successful broadcast scheme would require both a well-engineered >high-reliability transmission scheme (good paths, no hidden terminals etc) >and a protocol that gets no worse than multiple-VCs even in poor conditions. >It might work pretty well with a full-duplex repeater and extremely well >with a polled hub (where a small amount of reverse traffic can be effectively >free by imposing no additional overhead). > >I don't know how closely satellite operation approaches this (do they split >uplink and downlink packet frequencies ? ). I'd be interested to hear from >users of the Pacsat broadcast system and even more interested to hear from >anyone who has experimented with a terrestrial broadcast setup. Dan -- --------------------------------------------------------------- Daniel Senie Internet: dts@world.std.com Daniel Senie Consulting n1jeb@world.std.com 508-779-0439 Compuserve: 74176,1347 ------------------------------ Date: 25 Aug 1994 13:51:55 +0100 From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!EU.net!uknet!acorn!not-for-mail@network.ucsd.edu To: ham-digital@ucsd.edu References <3306v8$jbi@vixen.cso.uiuc.edu>, <1994Aug20.143652.9960@ke4zv.atl.ga.us>, Subject : Re: Looking for DXCluster software In article , Daniel T Senie wrote: > >How is the PacketCluster machine to know that the UI frame with a DX >spot just got stomped by another station starting to transmit a frame? >Packet radio does NOT run with Collision Detection in the way that >Ethernet does. You cannot tell, when transmitting, that your frame >has just gotten munched. > It's not that difficult : most broadcast protocols work on a NAK-only scheme - clients of the server respond only when they miss a packet, and the server than retransmits it. The method of detecting that missed packet varies, but a popular method is to number the transmitted packets and complain when a hole appears in the number sequence. This has some difficulties for a DX-Cluster style service : as I understand it (I don't use DX Cluster) you expect transmissions at intervals, rather than a continuous stream. Thus, you wouldn't know you missed one until the next arrived - a second or an hour later. Regular empty packets, sent just to ensure everyone was up to date, might be sufficent to fix this, and there are more sophisticated schemes around to ensure this doesn't itself become a bandwidth hog. These require that the server keep track of its clients rather than doing pure broadcast, but that's no worse than having multiple VCs. However, I think you're correct to be concerned about low reliability of packet systems - on typical terrestrial packet, the success rate is very low. As a result, a protocol optimised for the assumption that most packets get through (and don't require ACKing) might turn out disastrously wrong - I think a successful broadcast scheme would require both a well-engineered high-reliability transmission scheme (good paths, no hidden terminals etc) and a protocol that gets no worse than multiple-VCs even in poor conditions. It might work pretty well with a full-duplex repeater and extremely well with a polled hub (where a small amount of reverse traffic can be effectively free by imposing no additional overhead). I don't know how closely satellite operation approaches this (do they split uplink and downlink packet frequencies ? ). I'd be interested to hear from users of the Pacsat broadcast system and even more interested to hear from anyone who has experimented with a terrestrial broadcast setup. -adrian ------------------------------ End of Ham-Digital Digest V94 #285 ******************************